The Third Generation Partnership Project (3GPP) is currently working on standardization of Release 13 of the Long Term Evolution (LTE) concept. FIG. 1 illustrates an exemplary architecture of the LTE system. As depicted, the LTE system includes radio access nodes (e.g., Evolved Node Bs (eNBs), Home eNBs—HeNBs, HeNB GW) and evolved packet core nodes (MME/S-GW). As it can be seen a S1 interface connects HeNBs/eNBs to the MME/S-GW and HeNBs to the HeNB GW, while an X2 interface connects peer eNBs/HeNBs, optionally via an X2 GW.
FIG. 2 illustrates an exemplary management system. The network nodes also referred to as eNodeB, are managed by an Operations, Administration, and Management (OAM) system. As depicted, the OAM system is comprised of a network manager (NM) that manages one or more domain managers (DM). A DM may also be referred to as the operation and support system (OSS). Two network nodes are interfaced by an X2 interface. The interface between two DMs may be referred to as Itf-P2P but may not be applicable. The management system may configure the network node, as well as receive observations associated to features in the network nodes. For example, DM observes and configures network nodes, while NM observes and configures DMs, as well as network nodes via the DMs.
Using configurations via the DMs, NM, and related interfaces, functions over the X2 and S1 interfaces can be carried out in a coordinated way throughout the RAN, eventually involving the Core Network, such as, for example, MME and S-GWs.
In Network Sharing scenarios, different management architectures may exist. In this disclosure it is assumed that the Shared E-UTRAN has a single DM. Each Sharing operator can have their own operations, administration, and management (OAM) capabilities but information exchanged needs to be controlled by the Master operator.
Selected OAM capabilities for the Shared E-UTRAN, under the control of the Master E-UTRAN Operator, may be accessible by the Sharing Operator's OAM functions. This allows, for example, the Sharing Operator to i) test of communication path between the Sharing Operator's network elements and the Shared E-UTRAN, ii) obtain fault reports and iii) retrieve RAN resource usage information.
Recent studies in the area of LTE have looked at how operators can share common radio resources, according to identified RAN sharing scenarios. This area is often referred to as RAN Sharing or RAN Sharing Enhancements. Within this context of RAN Sharing Enhancements, proposals have been made to allow an operator to collect statistics about the data volumes consumed within a shared Radio Access Network (RAN) and collected per sharing operator, i.e., per Public Land Mobile Network (PLMN) ID, and per Quality of Service (QoS) parameters. Some examples of proposals for reporting data volumes in RAN Sharing may include: R3-152126, Measuring resource usage for shared E-UTRAN (TeliaSonera); R3-152180, Proposed answers to SA5 and trade-off between complexity and filtering granularity (Alcatel-Lucent); R3-151634, Data Volume Reporting in RAN Sharing (Ericsson); R3-151599, Simplifications for implementation of data volume counters (Alcatel-Lucent); R3-151675, Introduction of QoS profiles in the measurements for RAN sharing (TeliaSonera AB); and R3-151848, Reply LS on RAN Sharing Enhancements for LTE (To: RAN3. The proposals describe approaches to a problem that was discussed in 3GPP RAN3 and that concerns how to collect Data Volume Reports on a per-sharing-operator basis and on a per-QoS-parameters basis.
The proposals consist of re-using performance management counters, such as the counters related to the performance of the RAN collected at the eNB and reported periodically and/or on an event basis to the OAM system. Specifically, counters related to one or all of the following parameters may be collected:                Data Volumes Per PLMN ID        Data Volumes Per UL/DL traffic direction        Data Volumes Per QoS Class Indicator (QCI) or group of QCIs        Data Volumes Per Allocation and Retention Priority (ARP) value or group of ARP        Data Volumes Per Guaranteed Bit Rate (GBR) Band, i.e. a range of target GBRs within which the bearer traffic has its target GBR        
There are several drawbacks to the current approaches to data volume reporting in RAN sharing situations. For example, the total number of counters deriving from the required data volume filtering criteria may reach several hundred thousand filtering criteria counters or even millions of counters collected internally to the eNB. Even if a limit is imposed on the number of counters the eNB can report to the OAM system, two problems may still occur. First, an eNB may need to collect all the counters corresponding to the newly available filtering criteria in order to extract and report to the OAM the relevant data volumes. Second, even if the eNB collects data volumes only for the relevant counters that need to be reported to the OAM, the overall number of performance management (PM) counters to be collected may be too high for the eNB, resulting in some of the counters being corrupted.
In one example implementation, enhancements on new data volume reporting counters for RAN Sharing are being introduced to let operators participating in a shared RAN to appropriately charge each other on the basis of the data volumes consumed per QoS parameters. Therefore, these counters—specifically those counters that are used for billing purposes—should be collected in a reliable and robust way.
However, the current mechanisms to collect PM counters do not ensure such robustness. Indeed, in R3-151848, Reply LS on RAN Sharing Enhancements for LTE (To: RAN3; Cc: SA1, RAN2) (SA5, Nokia) it has been noted that current PM mechanisms support periodic (but not true real-time) measurement reporting only. The smallest measurement reporting period is 5 minutes. Additionally, as specified in TS 32.401, Performance Management (PM), Concept and Requirement (Release 13), v13.0.0 and TS 32.432, Performance Management, File Format Definition, (Release 12), v12.0.0, PM reporting may include a “suspect flag” indicating whether the measurement result is reliable in the measurement report. Thus, it may be recognized that the PM counters mechanism, to be used for reporting the new data volume reports for RAN Sharing, is subject to unreliability. For example, the reports could be corrupted, in which case a “suspect flag” would be set, indicating that the whole reporting period is affected.
Moreover, the eNB must retain performance measurement result data until they have been sent to, or retrieved by, the destination EM (Element Manager) and/or NM (Network Manager). Also as specified in TS 32.401, Performance Management (PM), Concept and Requirement (Release 13), v13.0.0, the storage capacity and the duration for which the data is retained at the eNB are Operator and implementation dependent.
As a result potential problems exist with respect to RAN sharing data volumes even though the data volumes may be used for cross sharing operator charging, such as, for example, helping operators settle a bill coming from consuming data at certain QoS levels on a shared RAN. However, PM counters are not designed to provide the reliability that charging data should be subject to.
Given that storage space and data retention duration is operator- and/or implementation-specific and may be limited, and given that there are numerous PM counters reported by the eNB to the OAM system, errors in the new data volume reports because of corruption, eNB internal limitations such as lack of memory, lack of processing resources, and the like may cause considerable damage to operators where the operators are not able to produce billing data for the whole time period covered by the corrupted data.